\chapter{Поиск в коде того что нужно}

Современное ПО, в общем-то, минимализмом не отличается.

\myindex{\Cpp!STL}
Но не потому, что программисты слишком много пишут, 
а потому что к исполняемым файлам обыкновенно прикомпилируют все подряд библиотеки. 
Если бы все вспомогательные библиотеки всегда выносили во внешние DLL, мир был бы иным.
(Еще одна причина для Си++ --- \ac{STL} и прочие библиотеки шаблонов.)

\newcommand{\FOOTNOTEBOOST}{\footnote{\url{http://go.yurichev.com/17036}}}
\newcommand{\FOOTNOTELIBPNG}{\footnote{\url{http://go.yurichev.com/17037}}}

Таким образом, очень полезно сразу понимать, какая функция из стандартной библиотеки или 
более-менее известной (как Boost\FOOTNOTEBOOST, libpng\FOOTNOTELIBPNG), 
а какая --- имеет отношение к тому что мы пытаемся найти в коде.

Переписывать весь код на \CCpp, чтобы разобраться в нем, безусловно, не имеет никакого смысла.

Одна из важных задач reverse engineer-а это быстрый поиск в коде того что собственно его интересует.

\myindex{\GrepUsage}
Дизассемблер \IDA позволяет делать поиск как минимум строк, последовательностей байт, констант.
Можно даже сделать экспорт кода в текстовый файл .lst или .asm и затем натравить на него \TT{grep}, \TT{awk}, итд.

Когда вы пытаетесь понять, что делает тот или иной код, это запросто может быть какая-то 
опенсорсная библиотека вроде libpng. Поэтому, когда находите константы, или текстовые строки, которые 
выглядят явно знакомыми, всегда полезно их \IT{погуглить}.
А если вы найдете искомый опенсорсный проект где это используется, 
то тогда будет достаточно будет просто сравнить вашу функцию с ней. 
Это решит часть проблем.

К примеру, если программа использует какие-то XML-файлы, первым шагом может быть
установление, какая именно XML-библиотека для этого используется, ведь часто используется какая-то
стандартная (или очень известная) вместо самодельной.

\myindex{SAP}
\myindex{Windows!PDB}
К примеру, автор этих строк однажды пытался разобраться как происходит компрессия/декомпрессия сетевых пакетов в SAP 6.0. 
Это очень большая программа, но к ней идет подробный .\gls{PDB}-файл с отладочной информацией, и это очень удобно. 
Он в конце концов пришел к тому что одна из функций декомпрессирующая пакеты называется CsDecomprLZC(). 
Не сильно раздумывая, он решил погуглить и оказалось, что функция с таким же названием имеется в MaxDB
(это опен-сорсный проект SAP) \footnote{Больше об этом в соответствующей секции~(\myref{sec:SAPGUI})}.

\url{http://www.google.com/search?q=CsDecomprLZC}

Каково же было мое удивление, когда оказалось, что в MaxDB используется точно такой же алгоритм, 
скорее всего, с таким же исходником.

\input{digging_into_code/identification/exec_RU}
% binary files might be also here

\section{Связь с внешним миром (на уровне функции)}
Очень желательно следить за аргументами ф-ции и возвращаемыми значениями, в отладчике или \ac{DBI}.
Например, автор этих строк однажды пытался понять значение некоторой очень запутанной ф-ции, которая, как потом оказалось,
была неверно реализованной пузырьковой сортировкой\footnote{\url{https://yurichev.com/blog/weird_sort/}}.
(Она работала правильно, но медленнее.)
В то же время, наблюдение за входами и выходами этой ф-ции помогает мгновенно понять, что она делает.

Часто, когда вы видите деление через умножение (\myref{sec:divisionbymult}),
но забыли все детали о том, как оно работает, вы можете просто наблюдать за входом и выходом, и так быстро найти делитель.

% sections:
\input{digging_into_code/communication_win32_RU}
\input{digging_into_code/strings_RU}
\input{digging_into_code/assert_RU}
\input{digging_into_code/constants_RU}
\input{digging_into_code/instructions_RU}
\input{digging_into_code/suspicious_code_RU}
\input{digging_into_code/magic_numbers_tracing_RU}
\input{digging_into_code/loops_RU}
\input{digging_into_code/binary/main_RU}
\input{digging_into_code/snapshots_comparing_RU}
\input{digging_into_code/ISA_detect_RU}

\section{Прочее}

\subsection{Общая идея}

Нужно стараться как можно чаще ставить себя на место программиста и задавать себе вопрос, 
как бы вы сделали ту или иную вещь в этом случае и в этой программе.

\subsection{Порядок функций в бинарном коде}

Все функции расположеные в одном .c или .cpp файле компилируются в соответствующий объектный (.o) файл.
Линкер впоследствии складывает все нужные объектные файлы вместе, не меняя порядок ф-ций в них.
Как следствие, если вы видите в коде две или более идущих подряд ф-ций, то это означает, что и в исходном коде они 
были расположены в одном и том же файле (если только вы не на границе двух объектных файлов, конечно).
Это может означать, что эти ф-ции имеют что-то общее между собой, что они из одного слоя \ac{API}, из одной библиотеки, итд.%

\subsection{Крохотные функции}

Крохотные ф-ции, такие как пустые ф-ции (\myref{empty_func})
или ф-ции возвращающие только ``true'' (1) или ``false'' (0) (\myref{ret_val_func}) очень часто встречаются,
и почти все современные компиляторы, как правило, помещают только одну такую ф-цию в исполняемый код,
даже если в исходном их было много одинаковых.
Так что если вы видите ф-цию состояющую только из \TT{mov eax, 1 / ret}, которая может вызываться из разных мест,
которые, судя по всему, друг с другом никак не связаны, это может быть результат подобной оптимизации.

\subsection{\Cpp}

\ac{RTTI}~(\myref{RTTI})-информация также может быть полезна для идентификации 
классов в \Cpp.

